Privilege management and revocation

ABSTRACT

This disclosure relates to management of privileges associated with applications accessible by users of electronic devices. In one aspect, an electronic device detects that a privilege has been revoked, shuts down any application running on the electronic device that has previously accessed the privilege, and restarts any application that was shut down, the restarted application no longer having any access to the revoked privilege. In another aspect, an electronic device keeps a log of which applications have previously accessed which privileges, receives a new set of privileges associated with applications, determines that a privilege has been revoked, and if the log indicates that an application previously accessed the privilege, resets the electronic device. In a further aspect, a method sets privileges associated with applications, records which electronic devices have which applications, revokes a privilege, and instructs those electronic devices having applications to which the privilege is associated to reset themselves.

FIELD OF THE INVENTION

The present invention relates generally to the management of privilegesassociated with certain applications that are accessible by users ofelectronic equipment, such as, for example, networked computers, mobilewireless communications devices, and the like. In particular, thedisclosure is directed to systems and methods for managing privilegesassociated with particular applications and for revoking theseprivileges in a timely and robust manner.

RELATED ART

It is well known that certain electronic equipment, such as, forexample, networked computers, mobile wireless communications devices,and the like, include applications resident on such equipment that mayhave access to certain privileges that enable the applications toperform various functions. Typically, a system administrator may use ITpolicy and application control to set the privileges associated withvarious applications present on the equipment that is subject to theadministrator's control. Examples of privileges may include, forexample, allowing an application to use inter-process communication(IPC), enabling the opening of internal and external connections,enabling the injection of browser filters, enabling Bluetooth™functionality, enabling use of e-mail, enabling the use of personalinformation management (PIM) functionality, use of application programinterface (API), etc. It is important for the system administrator beable to track which applications have access to which privileges, and tobe able to revoke privileges on an as needed basis.

For example, if an application has access to a privilege, and the systemadministrator revokes that privilege, the application shouldimmediately, or within a small window of time, be denied access to thatprivilege. In other words, the privilege should be revoked as soon aspossible. Events that might trigger a revocation of privileges mayinclude, for example, an application being loaded before the ITadministrator/application control data is present on the device, anapplication is discovered to be a rogue application, or company policychanges, resulting in limiting the use or availability of certainapplications and/or privileges associated therewith.

Regardless of the reason for privilege revocation, such revocation mustbe accomplished in a secure manner and in a manner that preventspossible work arounds by malicious applications or individuals. Ingeneral, according to current privilege revocation schemes, privilegechecking is typically performed on the first access to a privilege. Forexample, applications communicate with IPC using the applicationregistry. Once an application has a reference (e.g., pointer) to theapplication registry, it is difficult to take this reference away fromthe application. In another example, if an application has passed someif its privileges to another application using IPC, conventional systemscan detect that the first application has access to IPC, but there is noway to detect that the other application has been passed theprivilege(s).

Therefore, there remains a need for a system and method for effectivelymanaging privileges associated with applications, and in particular,when privilege revocation is required, to revoke these privileges in atimely and robust manner.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other embodiments along with their attendant advantages aredescribed herein with reference to the following drawings in which likereference numerals refer to like elements, and wherein:

FIG. 1 is a block diagram showing a computer network and communicationsystem in which electronic devices running applications having access toassociated privileges are used;

FIG. 2 is a block diagram of a wireless mobile communication device asan example of an electronic device running applications having access toassociated privileges;

FIG. 3 is a flow diagram illustrating a method of revoking privilegesaccording to an exemplary embodiment;

FIG. 4 is a flow diagram illustrating a method of revoking privilegesaccording to another exemplary embodiment; and

FIG. 5 is a flow diagram illustrating yet another method of revokingprivileges according to another exemplary embodiment.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In view of the foregoing, we have now identified an efficient, accurate,robust and easy to implement system and method for managing privilegesassociated with particular applications and for revoking theseprivileges in a timely and reliable manner

According to an exemplary embodiment an application having privilegesthat are to be revoked may be shut down. When this application isrestarted, access to revoked privileges will be denied. In order to keeptrack of which applications need to be shut down and reset, the systemmust keep track of which applications have accessed which privileges. Toenable monitoring of the privileges accessed by applications, each timean application uses a privilege, the system records the applicationidentifier and which privilege has been accessed. This may be done inany of a number of conventional methods, such as, for example, a datatable listing the application identifier and corresponding accessedprivilege(s) associated with the application identifier. When the systemadministrator, or any other authority, institutes a change inprivileges, the system accesses the record of which applications haveaccessed which privileges. A comparison of accessed privileges with theprivileges to be revoked is performed. Each application that hasaccessed a privilege that is to be revoked is identified by the systemand then shut down. When the application is restarted, the applicationwill not have access to any of the revoked privileges.

In another embodiment, a device reset may be performed. By resetting adevice, the system is brought to a known state. According to thisembodiment, a system administrator, or any other authority, specifiesthat a device must be reset when a new policy that revokes (or changes)privileges is instituted. A device reset may be instituted at any timethe administrator or authority deems it necessary to do so. For example,a device reset may be done whenever a new policy that includes privilegerevocation is instituted. However, this may result in numerousunnecessary device reset events that are potentially inconvenient to theuser and may interfere with use of the device. Alternatively, the systemmay keep track of which devices include which applications, and use thisinformation to determine a less intrusive device reset schedule. Forexample, resetting only those devices having applications that maypotentially be affected by the policy change.

In yet another advantageous embodiment, aspects of previously describedembodiments are combined to provide effective privilege management andrevocation. According to this exemplary embodiment, the systemadministrator or other authority has no actual control over when adevice is reset. The administrator merely manages the privileges of thesystem and particular applications. The device itself is responsible forresetting when necessary. In this embodiment, the device keeps track ofwhich applications get access to which privileges. When policies orapplication control changes, the system detects which privileges havebeen revoked for which applications. This can be accomplished by simplycomparing the old set of privileges with the new set of privileges. Foreach revoked privilege for a given application, the system determines ifthe application has ever accessed that privilege in the past. As notedabove, the system has been keeping track of these since the system wasfirst started up. If an application has accessed a privilege that is nowrevoked at any time in the past, the device is reset. For someprivileges (e.g., IPC), it still cannot be determined whether aprivilege has been used as a result of being passed from anotherapplication. To overcome the potential for missing a revocation ofprivileges when applications pass privileges between themselves, if, forexample, IPC (or any other privilege that is able to be passed betweenapplications) is revoked from any application, regardless of if thesystem has detected that the application has accessed the privilege, thedevice must be reset. This reset will bring the device back to a knownstate. Device reset will only be done when necessary, thus limiting thenumber of resets and solving the problem associated with privileges thathave been passed between applications.

Each of these embodiments is useful in a variety of privilege managementenvironments ranging from a low-level low-priority where a modest levelof privilege revocation security is needed, resulting in a less robustsystem, to a highly important ultra-robust environment where userinconvenience is secondary to the need for absolute certainty ofprivilege revocation.

FIG. 1 is a block diagram showing a computer network and communicationsystem in which electronic devices running applications having access toassociated privileges are used. The computer network 18 includes, forexample, various networked computers 28 and, optionally, a messageserver 26, all linked via a Local Area Network (LAN) 30. Thecommunication system includes a Wide Area Network (WAN) 12 coupled to acomputer system 14, a wireless network gateway 16 and the LAN 30 of thecomputer network 18. The wireless network gateway 16 is also connectedto a wireless communication network 20 in which a wireless mobilecommunication device 22 (hereinafter “mobile device”), is configured tooperate. The entire system 10 is typically managed by, among others, asystem administrator or like authority 32.

The computer system 14 may be a desktop or laptop personal computer thatis configured to communicate with the WAN 12 or any other suitablenetwork, such as, for example, the Internet. Personal computers, such asthe computer system 14, typically access the Internet via an InternetService Provider (ISP), Application Service Provider (ASP), or the like.

The LAN 30 is an example of a typical working computer networkenvironment, in which multiple computers 28 are connected in a network.The computer network 18 is typically located behind a security firewall24. Within the LAN 30, a message server 26, operating on a computerbehind the firewall 24 may act as the primary interface for the owner ofthe computer network 18 to exchange messages both within the LAN 30 andwith other external messaging clients via the WAN 12. Known messageservers include, for example, Microsoft Outlook®, Lotus Notes®, Yahoo!®Messenger®, AOL Instant Messenger®, or any other client-server orpeer-to-peer, or similar messaging clients with various architectures.Messages received by the message server 26 are distributed to mailboxesfor user accounts addressed in the received messages, and are thenaccessed by a user through a messaging client operating on a computersystem 28. The foregoing is merely an exemplary description illustratinga client-server architecture, and in no way implies that sucharchitecture is necessary, as other suitable architectures known tothose skilled in the art may be used.

Although only a message server 26 is shown in the LAN 30, those skilledin the art will appreciate that a LAN may include other types of serverssupporting resources that are shared between the networked computersystems 28, and that the message server 26 may also provide additionalfunctionality, such as dynamic database storage for data such as, butnot limited to, calendars, to-do lists, task lists, e-mail anddocumentation. The message server 26 and electronic messaging aredescribed for illustrative purposes only. Systems and methods formanaging and revoking privileges are applicable to a wide range ofelectronic devices, and are in no way limited to electronic devices withmessaging capabilities.

The wireless gateway 16 provides an interface to a wireless network 20,through which messages may be exchanged with a mobile device 22. Suchfunctions as addressing of the mobile device 22, encoding or otherwisetransforming messages for wireless transmission, and any other interfacefunctions are performed by the wireless gateway 16. The wireless gateway16 may be configured to operate with more than one wireless network 20,in which case the wireless gateway 16 also determines a most likelynetwork for locating a given mobile device 22 and possibly track mobiledevices as users roam between countries or networks.

The mobile device 22 is, for example, a data communication device, avoice communication device, a dual-mode communication device such asmany modern cellular telephones having both data and voicecommunications functionality, a multiple-mode device capable of voice,data and other types of communications, a personal digital assistant(PDA) enabled for wireless communications, or a laptop or desktopcomputer system with a wireless modem.

Any computer system with access to the WAN 12 may exchange messages withthe mobile device 22 through the wireless network gateway 16.Alternatively, private wireless network gateways such as wirelessVirtual Private Network (VPN) routers could be implemented to provide aprivate interface to a wireless network. A wireless VPN routerimplemented in the LAN 30 provides a private interface from the LAN 30to one or more mobile devices such as 22 through the wireless network20. A private interface to a mobile device 22 may also effectively beextended to entities outside the LAN 30 by providing a messageforwarding or redirection system that operates with the message server26. Such a message redirection system is disclosed in U.S. Pat. No.6,219,694, which is hereby incorporated into this application byreference. In this type of system, incoming messages received by themessage server 26 and addressed to a user of a mobile device 22 are sentthrough the wireless network interface, either a wireless VPN router,the wireless gateway 16, or another interface, for example, to thewireless network 20 and to the user's mobile device 22. Anotheralternate interface to a user's mailbox on a message server 26 may be aWireless Application Protocol (WAP) gateway. Through a WAP gateway, alist of messages in a user's mailbox on the message server 26, andpossibly each message or a portion of each message, may be sent to themobile device 22. A wireless network 20 normally delivers messages toand from communication devices such as the mobile device 22 via RFtransmissions between base stations and devices. The wireless network 20may, for example, be a data-centric wireless network, a voice-centricwireless network, or a dual-mode network that can support both voice anddata communications over the same infrastructure. Recently developednetworks include Code Division Multiple Access (CDMA) networks andGeneral Packet Radio Service (GPRS) networks. So-called third-generation(3G) networks like Enhanced Data rates for Global Evolution (EDGE) andUniversal Mobile Telecommunications Systems (UMTS) are currently underdevelopment. Older data-centric networks include, but are not limitedto, the Mobitex™ Radio Network (“Mobitex”), and the DataTAC™ RadioNetwork (“DataTAC”). Voice-centric data networks such as PersonalCommunication System (PCS) networks, including Global System for MobileCommunications (GSM) and Time Division Multiple Access (TDMA) systems,have been available in North America and world-wide for several years.

FIG. 2 is a block diagram of an exemplary wireless mobile communicationdevice as an example of an electronic device. However, it should beunderstood that the systems and methods disclosed herein may be usedwith many different types of devices, such as personal digitalassistants (PDAs), desktop computers, or the like.

The mobile device 500 is preferably a two-way communication devicehaving at least voice and data communication capabilities. The mobiledevice 500 preferably has the capability to communicate with othercomputer systems on the Internet. Depending on the functionalityprovided by the mobile device, the mobile device may be referred to as adata messaging device, a two-way pager, a cellular telephone with datamessaging capabilities, a wireless Internet appliance, or a datacommunication device (with or without telephony capabilities). Asmentioned above, such devices are referred to generally herein as mobiledevices.

The mobile device 500 includes a transceiver 511, a microprocessor 538,a display 522, non-volatile memory 524, random access memory (RAM) 526,auxiliary input/output (I/O) devices 528, a serial port 530, a keyboard532, a speaker 534, a microphone 536, a short-range wirelesscommunications sub-system 540, and may also include other devicesub-systems 542. The transceiver 511 preferably includes transmit andreceive antennas 516, 518, a receiver (Rx) 512, a transmitter (Tx) 514,one or more local oscillators (LOs) 513, and a digital signal processor(DSP) 520. Within the non-volatile memory 524, the mobile device 500includes a plurality of software modules 524A-524N that can be executedby the microprocessor 538 (and/or the DSP 520), including a voicecommunication module 524A, a data communication module 524B, and aplurality of other operational modules 524N for carrying out a pluralityof other functions.

The mobile device 500 is preferably a two-way communication devicehaving voice and data communication capabilities. Thus, for example, themobile device 500 may communicate over a voice network, such as any ofthe analog or digital cellular networks, and may also communicate over adata network. The voice and data networks are depicted in FIG. 2 by thecommunication tower 519. These voice and data networks may be separatecommunication networks using separate infrastructure, such as basestations, network controllers, etc., or they may be integrated into asingle wireless network. References to the network 519 should thereforebe interpreted as encompassing both a single voice and data network andseparate networks.

The communication subsystem 511 is used to communicate with the network519. The DSP 520 is used to send and receive communication signals toand from the transmitter 514 and receiver 512, and also exchange controlinformation with the transmitter 514 and receiver 512. If the voice anddata communications occur at a single frequency, or closely-spaced setof frequencies, then a single LO 513 may be used in conjunction with thetransmitter 514 and receiver 512. Alternatively, if differentfrequencies are utilized for voice communications versus datacommunications or the mobile device 500 is enabled for communications onmore than one network 519, then a plurality of LOs 513 can be used togenerate frequencies corresponding to those used in the network 519.Although two antennas 516, 518 are depicted in FIG. 2, the mobile device500 could be used with a single antenna structure. Information, whichincludes both voice and data information, is communicated to and fromthe communication module 511 via a link between the DSP 520 and themicroprocessor 538.

The detailed design of the communication subsystem 511, such asfrequency band, component selection, power level, etc., is dependentupon the communication network 519 in which the mobile device 500 isintended to operate. For example, a mobile device 500 intended tooperate in a North American market may include a communication subsystem511 designed to operate with the Mobitex or DataTAC mobile datacommunication networks and also designed to operate with any of avariety of voice communication networks, such as AMPS, TDMA, CDMA, PCS,etc., whereas a mobile device 500 intended for use in Europe may beconfigured to operate with the GPRS data communication network and theGSM voice communication network. Other types of data and voice networks,both separate and integrated, may also be utilized with the mobiledevice 500.

Communication network access requirements for the mobile device 500 alsovary depending upon the type of network 519. For example, in the Mobitexand DataTAC data networks, mobile devices are registered on the networkusing a unique identification number associated with each device. InGPRS data networks, however, network access is associated with asubscriber or user of the mobile device 500. A GPRS device typicallyrequires a subscriber identity module (“SIM”), which is required inorder to operate the mobile device 500 on a GPRS network. Local ornon-network communication functions (if any) may be operable, withoutthe SIM, but the mobile device 500 is unable to carry out functionsinvolving communications over the network 519, other than any legallyrequired operations, such as ‘911’ emergency calling.

After any required network registration or activation procedures havebeen completed, the mobile device 500 is able to send and receivecommunication signals, preferably including both voice and data signals,over the network 519. Signals received by the antenna 516 from thecommunication network 519 are routed to the receiver 512, which providesfor signal amplification, frequency down conversion, filtering, channelselection, etc., and may also provide analog to digital conversion.Analog to digital conversion of the received signal allows more complexcommunication functions, such as digital demodulation and decoding, tobe performed using the DSP 520. In a similar manner, signals to betransmitted to the network 519 are processed, including modulation andencoding, for example, by the DSP 520 and are then provided to thetransmitter 514 for digital to analog conversion, frequency upconversion, filtering, amplification and transmission to thecommunication network 519 via the antenna 518. Although a singletransceiver 511 is shown for both voice and data communications, inalternative embodiments, the mobile device 500 may include multipledistinct transceivers, such as a first transceiver for transmitting andreceiving voice signals, and a second transceiver for transmitting andreceiving data signals, or a first transceiver configured to operatewithin a first frequency band, and a second transceiver configured tooperate within a second frequency band.

In addition to processing the communication signals, the DSP 520 alsoprovides for receiver and transmitter control. For example, the gainlevels applied to communication signals in the receiver 512 andtransmitter 514 may be adaptively controlled through automatic gaincontrol algorithms implemented in the DSP 520. Other transceiver controlalgorithms could also be implemented in the DSP 520 in order to providemore sophisticated control of the transceiver 511.

The microprocessor 538 preferably manages and controls the overalloperation of the mobile device 500. Many types of microprocessors ormicrocontrollers could be used here, or, alternatively, a single DSP 520could be used to carry out the functions of the microprocessor 538.Low-level communication functions, including at least data and voicecommunications, are performed through the DSP 520 in the transceiver511. High-level communication applications, including the voicecommunication application 524A, and the data communication application524B are stored in the non-volatile memory 524 for execution by themicroprocessor 538. For example, the voice communication module 524A mayprovide a high-level user interface operable to transmit and receivevoice calls between the mobile device 500 and a plurality of other voicedevices via the network 519. Similarly, the data communication module524B may provide a high-level user interface operable for sending andreceiving data, such as e-mail messages, files, organizer information,short text messages, etc., between the mobile device 500 and a pluralityof other data devices via the network 519.

The microprocessor 538 also interacts with other device subsystems, suchas the display 522, RAM 526, auxiliary I/O devices 528, serial port 530,keyboard 532, speaker 534, microphone 536, a short-range communicationssubsystem 540 and any other device subsystems generally designated as542. For example, the modules 524A-N are executed by the microprocessor538 and may provide a high-level interface between a user of the mobiledevice and the mobile device. This interface typically includes agraphical component provided through the display 522, and aninput/output component provided through the auxiliary I/O devices 528,keyboard 532, speaker 534, or microphone 536. Additionally, themicroprocessor 538 is capable of running a variety of applications thatmay be present in the device non-volatile memory 524, includingapplications that have access to various privileges, as will bedescribed in more detail herein.

Some of the subsystems shown in FIG. 2 perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 532 and display522 may be used for both communication-related functions, such asentering a text message for transmission over a data communicationnetwork, and device-resident functions such as a calculator or task listor other PDA type functions.

Operating system software used by the microprocessor 538 is preferablystored in a persistent store such as the non-volatile memory 524. Inaddition to the operating system and communication modules 524A-N, thenon-volatile memory 524 may include a file system for storing data. Thenon-volatile memory 524 may also include data stores for ownerinformation and owner control information. The operating system,specific device applications or modules, or parts thereof, may betemporarily loaded into a volatile store, such as RAM 526 for fasteroperation. Moreover, received communication signals may also betemporarily stored to RAM 526, before permanently writing them to a filesystem located in the non-volatile memory 524. The non-volatile memory524 may be implemented, for example, with Flash memory, non-volatileRAM, or battery backed-up RAM.

An exemplary application module 524N that may be loaded onto the mobiledevice 500 is a PIM application providing PDA functionality, such ascalendar events, appointments, and task items. This module 524N may alsointeract with the voice communication module 524A for managing phonecalls, voice mails, etc., and may also interact with the datacommunication module 524B for managing e-mail communications and otherdata transmissions. Alternatively, all of the functionality of the voicecommunication module 524A and the data communication module 524B may beintegrated into the PIM module.

The non-volatile memory 524 preferably provides a file system tofacilitate storage of PIM data items on the device. The PIM applicationpreferably includes the ability to send and receive data items, eitherby itself, or in conjunction with the voice and data communicationmodules 524A, 524B, via the wireless network 519. The PIM data items arepreferably seamlessly integrated, synchronized and updated, via thewireless network 519, with a corresponding set of data items stored orassociated with a host computer system, thereby creating a mirroredsystem for data items associated with a particular user.

The mobile device 500 is manually synchronized with a host system byplacing the mobile device 500 in an interface cradle, which couples theserial port 530 of the mobile device 500 to a serial port of the hostsystem. The serial port 530 may also be used to insert owner informationand owner control information onto the mobile device 500 and to downloadother application modules 524N for installation on the mobile device500. This wired download path may further be used to load an encryptionkey onto the mobile device 500 for use in secure communications, whichis a more secure method than exchanging encryption information via thewireless network 519.

Owner information, owner control information and additional applicationmodules 524N may be loaded onto the mobile device 500 through thenetwork 519, through an auxiliary I/O subsystem 528, through theshort-range communications subsystem 540, or through any other suitablesubsystem 542, and installed by a user in the non-volatile memory 524 orRAM 526. Such flexibility in application installation increases thefunctionality of the mobile device 500 and may provide enhancedon-device functions, communication-related functions, or both. Forexample, secure communication applications may enable electroniccommerce functions and other such financial transactions to be performedusing the mobile device 500.

When the mobile device 500 is operating in a data communication mode, areceived signal, such as a text message or a web page download, will beprocessed by the transceiver 511 and provided to the microprocessor 538,which preferably further processes the received signal for output to thedisplay 522, or, alternatively, to an auxiliary I/O device 528. Ownerinformation, owner control information, commands or requests related toowner information or owner control information, and softwareapplications received by the transceiver 511 are processed as describedabove. A user of mobile device 500 may also compose data items, such asemail messages, using the keyboard 532, which is preferably a completealphanumeric keyboard laid out in the QWERTY style, although otherstyles of complete alphanumeric keyboards such as the known DVORAK stylemay also be used. User input to the mobile device 500 is furtherenhanced with the plurality of auxiliary I/O devices 528, which mayinclude a thumbwheel input device, a touchpad, a variety of switches, arocker input switch, etc. The composed data items input by the user arethen transmitted over the communication network 519 via the transceiver511.

When the mobile device 500 is operating in a voice communication mode,the overall operation of the mobile device 500 is substantially similarto the data mode, except that received signals are output to the speaker534 and voice signals for transmission are generated by a microphone536. In addition, the secure messaging techniques described above mightnot necessarily be applied to voice communications. Alternative voice oraudio I/O devices, such as a voice message recording subsystem, may alsobe implemented on the mobile device 500. Although voice or audio signaloutput is accomplished through the speaker 534, the display 522 may alsobe used to provide an indication of the identity of a calling party, theduration of a voice call, or other voice call related information. Forexample, the microprocessor 538, in conjunction with the voicecommunication module 524A and the operating system software, may detectthe caller identification information of an incoming voice call anddisplay it on the display 522.

A short-range communications subsystem 540 is also included in themobile device 500. For example, the subsystem 540 may include aninfrared device and associated circuits and components, or a Bluetoothor 802.11 short-range wireless communication module to provide forcommunication with similarly-enabled systems and devices. Thus, ownerinformation insertion, owner control information insertion, andapplication loading operations as described above may be enabled on themobile device 500 via the serial port 530 or other short-rangecommunications subsystem 540.

FIG. 2 represents a specific example of an electronic device in whichowner control systems and methods described herein may be implemented.Implementation of such systems and methods in other electronic deviceshaving further, fewer, or different components than those shown in FIG.2 would occur to one skilled in the art to which this applicationpertains and are therefore considered to be within the scope of thepresent application.

FIG. 3 is a flow diagram illustrating a method of revoking privilegesaccording to an exemplary embodiment. In this example, an applicationhaving privileges that are to be revoked may be shut down. When theapplication is restarted, access to revoked privileges will be denied.In order to keep track of which applications need to be shut down andreset, the system must keep track of which applications have access towhich privileges. To accomplish this, for example, the system monitorsand detects use of privileges by applications 300. The system may recordan application identifier associated with a particular application andwhich privilege has been accessed by the application 302. This may beaccomplished in any number of conventional methods that are readilyapparent to those skilled in the art. For example, a data table listingthe application identifier and having pointers directed to privilege(s)accessed by the application or associated with the applicationidentifier. The system then continues to monitor the system for anychange, for example, a change in IT policy, that might result in arevocation of privileges 304. So long as no such change is detected indecision block 304, the system continues to monitor and keep track ofapplications and associated privileges.

Upon a detection of a change that would result in revocation ofprivileges being accessed by applications in the system by the decisionblock 304, such as, for example, a change in IT policy, a comparison ofthe recorded data relating to the accessed privileges with a listing ofthe new privileges is performed 306. For example, the applicationidentifiers and associated accessed privileges recorded in step 302 arecompared to the new privilege list, or to a list of revoked privileges306. The changes discussed herein are typically instituted andadministered by a system administrator or other authority who hasresponsibility for operation and management of the system.

As a result of the comparison 306, each application that has accessed aprivilege(s) to be revoked is identified 308 by the system. Uponidentification of these applications, the system implements a shut downof these identified applications 310. When these applications arerestarted 312, the applications will not have access to any of therevoked privileges. The system will continue to monitor and detect theaccessing of privileges and associated applications as described above.

In another embodiment, as illustrated in the flow diagram of FIG. 4, adevice reset may be performed. According to this example, all devices inthe system are monitored 400. A system administrator or other authorityspecifies, for example, that whenever there is a change in system policythat requires revocation or changes in privileges 402, all devices inthe system must be reset 404. Resetting the devices brings the system toa known state, i.e., a state in which the system knows whichapplications have access to which privileges throughout the system. Uponrestarting these applications 406 after the device reset 404, theapplications will no longer have access to any of the revokedprivileges. According to this example, a device reset may be institutedany time the system administrator or authority deems it necessary to doso. For example, a device reset may be done whenever a new policy thatincludes privilege revocation is instituted. As a result, this solutionmay invoke numerous (potentially unnecessary) device reset events thatmay be intrusive and inconvenient for the users. However, thisembodiment provides very robust and timely privilege revocation, and isthus suitable to highly secure systems where privilege management ismore important than user convenience.

Turning now to FIG. 5, another advantageous embodiment implementingfeatures of both embodiments described above with respect to FIGS. 3 and4 is illustrated. According to this example, aspects of the previouslydescribed embodiments are combined to provide highly effective andtimely privilege management and revocation. In this example, the systemadministrator or authority has no actual control over when a device isreset. The administrator or authority merely manages the privileges ofthe system and of particular applications. The device itself isresponsible for resetting as needed.

In this example, the device monitors which applications of the devicehave access to which privileges 600, and a log of privileges for thedevice is kept 602. The device monitors whether policies or applicationcontrol changes are made in the system 604. If there is no changedetected 604, the device continues to monitor applications and keep alog of privileges for the device 600, 602. If a change in policy orapplication control is detected in step 604, the system determines whichprivileges have been revoked for which applications by comparing the oldset of privileges in the log with the new set of privileges receivedfrom the system administrator 606. The device then determines if anyrevoked privileges are present on the device 608. If revoked privilegesare detected, e.g., if an application has accessed a privilege at anytime in the past that has now been revoked, the device will reset 610.As described above, resetting the device brings the system to a knownstate in which all applications and privileges are known. After thedevice is reset 610, it is restarted 612. Upon restart 612, the deviceapplications will have access to the correct privileges. Advantageously,if no revoked privileges are detected in step 608, the device performsanother check to ensure that no privileges that have been passed betweenapplication have been missed. As explained above, for some privileges,e.g., IPC, it cannot be determined whether a privilege has been used asa result of being passed from another application. To overcome thepotential for missing revocation of privileges when applications passprivileges between themselves, the system checks for privileges that areable to be passed between applications (e.g., IPC) 614. If a privilegethat is able to be passed between applications is revoked from anyapplication, regardless of if the system has detected that theapplication has accessed the privilege 614, the device must be reset 610to bring the system to a known state. After resetting, the device isrestarted 612, and will now have the only have access to the correctprivileges. In this manner, device reset will only be performed whennecessary, thus limiting the number of resets and solving the problemassociated with privileges that go undetected due to their ability to bepassed between applications.

While this disclosure describes specific exemplary embodiments, it isevident that many alternatives, modifications and variations will beapparent to those skilled in the art. Accordingly, the exemplaryembodiments described herein, are intended to be illustrative, notlimiting. Various changes may be made without departing from the truespirit and full scope of the invention, as defined in the followingclaims.

What is claimed is:
 1. A method performed by an electronic device, the method comprising: identifying that a privilege has been accessed by an application on the electronic device; receiving a new set of privileges associated with applications on the electronic device via a communication interface; determining that the privilege has been revoked by comparing the new set to an old set of privileges associated with the applications; and if any one of the applications on the electronic device previously accessed the revoked privilege, preventing the application from accessing the privilege.
 2. The method as recited in claim 1, further comprising resetting the electronic device responsive to determining that the revoked privilege is capable of being passed between applications.
 3. An electronic device comprising a processor configured to: identify that a privilege has been accessed by an application on the electronic device; receive a new set of privileges associated with applications on the electronic device via a communication interface; determine that the privilege has been revoked by comparing the new set to an old set of privileges associated with the applications; and if any one of the applications on the electronic device previously accessed the revoked privilege, prevent the application from accessing the privilege.
 4. The electronic device as recited in claim 3, the processor further configured to reset the electronic device responsive to determining that the revoked privilege is capable of being passed between applications.
 5. A non-transitory computer-readable medium storing instructions which, when executed by a processor of an electronic device, result in: identifying that a privilege has been accessed by an application on the electronic device; receiving a new set of privileges associated with applications on the electronic device via a communication interface; determining that the privilege has been revoked by comparing the new set to an old set of privileges associated with the applications; and if any one of the applications on the electronic device previously accessed the revoked privilege, preventing the application from accessing the privilege.
 6. The non-transitory computer-readable medium as recited in claim 5, wherein the instructions, when executed by the processor, further result in resetting the electronic device responsive to determining that the revoked privilege is capable of being passed between applications. 